home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 571 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.1 KB
  1. From: itschere@techfak.uni-bielefeld.de
  2. Subject: i/o speed (was: pipes & ptys)
  3. Date: Fri, 22 Oct 93 13:36:02 MET
  4. In-Reply-To: <9310202156.AA00230@jelal.north.de>; from "Juergen Lock" at Oct 20, 93 10:56:08 pm
  5.  
  6. Juergen Lock
  7.  
  8. > > Ok, got this, but: (see my other mail) it will return as soon as ther is
  9. > > some data, say, when it get's its next time slice, which is 16ms long on
  10. > > my 60Hz TT-VBL, right? Now I estimate that the writer (if really using 1
  11. > > bytes I/O), doesn't manage to output more than something like 30 chars per
  12. > > timeslice, so 60 slices a 30 bytes (always completely ignoring the time
  13. > > I need to read the data),~
  14. >
  15. >  this is the time we're trying to improve...
  16.  
  17. feel free to do so... :-)
  18.  
  19. > > makes 1800 CPS, and that looks like the number I've measured.
  20. >
  21. >  how much cps does the writer get when you send it to /dev/null
  22. > instead?  the difference between that and your 1800 is the only thing
  23. > we can improve here of course... for more the writing program has to
  24. > use longer writes.
  25.  
  26. naturally more, don't know exactly, but sure not 10 times as much... :-(
  27.  
  28. to summarize it:
  29.  
  30. if a program chooses to output one char, say, through a piped pseudo
  31. terminal, it looks more or less like this:
  32.  
  33. Cconout('!') ->
  34. Fwrite(?, 1, "!") ->
  35. tty_write(...) ->
  36. tty_putchar() ->
  37. pipe_write().
  38.  
  39. and the reader get's:
  40.  
  41. Fread() ->
  42. tty_read() ->
  43. tty_getchar() ->
  44. pipe_read().
  45.  
  46. and in the meantime, half an hour is gone... ;-(
  47.  
  48. > > If a) you really use big chunks and b) modems are operated by interrupt...
  49. > 
  50. >  yup!  actually modems are operated by interrupts already, only
  51. > the buffer status is still polled and data is read/written
  52. > one-byte-at-a-time...
  53.  
  54. to be more accurate, only incoming bytes raise an interrupt, but for outgoing
  55. the i/o chip is polled to see if it's ready. perhaps not immediately after the
  56. byte was send away, but before a char is to be send. at least the MFP does also
  57. support an interrupt for "output-buffer-empty", the newer chips also, I think.
  58. but as far as I know, these are not used so far.
  59.  
  60. by using these and a new buffer managing, completely obsoleting the bios,
  61. you'll gain lots of speed, I presume... :-)
  62.  
  63. bios routines may then be emulated with an fwrite(1,...) call for
  64. backwards compatibility.
  65.  
  66. > > Well, to make the biosfs drives expect char pointers instead longs. None
  67. > > of my program _seems_ to complain about this. But obviously that's no
  68. > > compatible solution... ;-)
  69. > 
  70. >  and i guess none of your programs use scan codes...
  71.  
  72. good question... I THINK not, since if I use a modem channel, the remote one
  73. is likely not to be an atari, and if i use pseudo ttys, all I want are things
  74. like cursor keys, and I can get these by using XKEY emulation. at least it
  75. looks like this works for tcsh, jove & emacs on pipes. correct me if I'm
  76. wrong. So I THINK just MiNT itself and... well... really, for me, nothing
  77. else uses scan codes.
  78.  
  79. bye,
  80. TeSche
  81. ---
  82. PS: If the above written looks weird, than that's because it probably IS.
  83. WhoDunnIt: Torsten Scherer (Schiller, TeSche...)
  84. Technical Faculty, University of Bielefeld, Germany (53'5"N 8'35"E)
  85. EMail: itschere@techfak.uni-bielefeld.de / tesche@dave.hrz.uni-bielefeld.de
  86.